目录

面试题

Redis到底是多线程还是单线程？

简单回答

详解

Redis的“单线程”

Redis为什么选择单线程？

后来Redis为什么又逐渐加入了多线程特性？

Redis为什么快？

回答

IO多路复用

Unix网络编程的5种IO模型

主线程和IO线程怎么协作完成请求处理的

四个阶段

浅谈IO多路复用

文件描述符（FileDescriptor, FD）

什么是IO多路复用

场景模拟

总结

Redis 7 默认设置是否开启了多线程？

总结

这篇我们从几个面试题入手

Redis 是从4开始慢慢支持多线程的，直到 Redis6/7 后才稳定

这种问法其实并不严谨，单线程还是多线程需要视版本而定。

Redis的版本很多3.X、4.X、6.X，版本不同架构也是不同的，不限定版本问是否单线程也不太严谨。

版本3.×（最早版本），也就是大家口口相传的Redis是单线程；

版本4.×，严格意义来说也不是单线程，而是负责处理客户端请求的线程单线程，但是开始加了点多线程的东西（异步删除）；

版本6.x 开始，全面支持多线程。

Redis的“单线程”主要是指Redis的网络IO和键值对读写是由一个线程来完成的，Redis在处理客户端的请求时包括获取（socket读）、解析、执行、内容返回（socket写）等都由一个顺序串行的主线程处理（第一篇介绍过的那些原子的命令），这也是Redis对外提供键值存储服务的主要流程。

Redis采用Reactor模式的网络模型，对于一个客户端请求，主线程负责一个完整的处理过程，如下图：

补充：

Reactor 模式是一种并发模型，在这种模型中，主线程（Reactor）避免了由于等待一或多个并发事件（比如 I/O 操作）的完成而无法继续工作的阻塞。通过使用非阻塞 I/O 操作和事件通知，主线程在并发操作完成时得到通知。

一般来说，Reactor 模式的工作流程如下：

这种模型非常适合于大并发，少逻辑的网络程序中，比如 Nginx 中就用到了这种设计模式。通过这种方式，一个线程可以处理很多连接的事件，而不需要为每个连接都创建一个线程，这样就可以避免线程切换的开销，并且可以更有效地使用系统资源。

但Redis的其他功能，比如持久化RDB、AOF、异步删除、集群同步数据等都是由额外的线程执行的，因此整个Redis可以看作是多线程的。

准确的说，应该是Redis 4.0之前一直采用单线程

主要原因有：

总的来说，就是与时俱进(￣∇￣)/🎉～～～

Redis 3.0 单线程时代依旧很快的原因：

现在Redis快的原因

在上面原因的基础上

接下来我们详细介绍下IO多路复用

IO多路复用（IO multiplexing）是Unix网络编程的5种IO模型之一。

Redis一直被大家熟知的就是它的单线程架构，虽然从Redis4.0开始使用了多线程，也是为了处理数据删除、快照删除等耗时操作，从网络IO处理到实际的读写命令处理都是由主线程独自处理的（心疼下主线程）。

在Redis 6/7中，Redis全面支持了多线程。这是由于随着硬件性能的提升，Redis的性能瓶颈主要出现在网络IO上，就是完全靠单个主线程处理网络请求的速度跟不上底层网络硬件的速度，于是采用多个线程处理网络IO，提高网络请求处理的并行度。

但是，Redis的多IO线程只是用来处理网络请求的，对于读写操作命令 Redis 仍然使用单线程来处理。这是因为，Redis处理请求时，网络处理经常是瓶颈，通过多个IO线程并行处理网络操作，可以提升实例的整体处理性能。而继续使用单线程执行命令操作，就不用为了保证Lua脚本、事务的原子性，额外开发多线程互斥加锁机制了（不管加锁操作处理），这样一来，Redis 线程模型实现就简单了。

由于IO多路复用（IO multiplexing）是Unix网络编程的5种IO模型之一，我们先介绍下Linux的相关内容，便于理解（熟悉的人可以直接跳到下一趴）。

在Linux中，一切皆文件，这就要提到“文件描述符”这个概念了。

文件描述符是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。

文件描述符在形式上是一个非负整数，实际上它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向该进程返回一个文件描述符。

在程序设计中，文件描述符这一概念往往只适用于UNIX或者Linux这样的操作系统。

一种同步的IO模型，实现一个线程监视多个文件句柄，一旦某个文件句柄就绪，就能通知到对应程序进行相应的读写操作，没有文件句柄就绪时，就会阻塞应用程序，从而释放CPU资源。

我们来介绍几个概念：

总结

不知道大家有没有注意过麻辣烫店是怎么做煮麻辣烫的，他们可不是一碗一碗单独的锅单独的灶煮的（太费💰），一般是有一个方形大锅，整个锅里加满水，下面一个灶加热，大锅里分成一个个小格子（就类似重庆火锅那种九宫格），每个小格子里煮一个客人选的菜。

基本流程就是，客人选完菜去收银那里称斤付款（人多则需要排队），服务员每收到一个客人选的菜，就把它们倒进一个小格子里煮，然后再回来收下一位的……还会时不时看看哪个小格子里的菜熟了，就把它盛到碗里，端回给客人

我们根据模拟情景来简单概括下IO多路复用模型：

将用户Socket对应的文件描述符（FileDescriptor）注册进epoll，然后epoll帮你监听哪些Socket上有消息到达，这样就避免了大量的无用操作，此时的Socket应该采用非阻塞模式，这样整个过程只在调用select、poll、epoll这些函数是才会阻塞，收发客户消息是不会阻塞的，整个进程/线程就会被充分利用起来，这就是事件驱动，所谓的reactor反应模式。

在单个线程通过记录跟踪每一个Socket（I/O流）的状态来同时管理多个I/O流，一个服务端进程可以同时处理多个套接字描述符，以此来提高服务器的吞吐能力。

大家都用过nginx，nginx使用epoll接收请求，ngnix会有很多链接进来，epoll会把他们都监视起来，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。Redis类似同理，这就是IO多路复用原理，有请求就响应，没请求不打扰。

IO多路复用达到的效果就是只使用一个服务端进程可以同时处理多个套接字描述符连接。

客户端请求服务端时，实际就是在服务端的Socket文件中写入客户端对应的文件描述符（FileDescriptor），如果有多个客户端同时请求服务端，为每次请求分配一个线程，类似每次来就new一个太耗费服务端资源，因此，只使用一个线程来监听多个文件描述符，即IO多路复用。

采用IO多路复用技术可以让单个线程高效的处理多个连接请求，一个服务端进程可以同时处理多个套接字描述符。

从Rdis6开始，就新增了多线程的功能来提高I/O的读写性能，他的主要实现思路是将主线程的IO读写任务拆分给一组独立的线程去执行，这样就可以使多个Socket的读写可以并行化了，采用多路I/O复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗)，将最耗时的Socket的读取、请求解析、写入单独外包出去，剩下的命令执行仍然由主线程串行执行并和内存的数据交互。

于是，网络IO操作就变成多线程了，其他核心操作仍然是主线程单独处理（线程安全）

如果你在实际应用中，发现Redis实例的CPU开销不大但吞吐量却没有提升，可以考虑使用Reds7的多线程机制（默认关闭，需手动开启），加速网络处理，进而提升实例的吞吐量。

Redis7将所有的数据放在内存中，内存的响应时长大约为100纳秒，对于小数据，Redis服务器可以处理8W到10W的QPS（实验室数据，极限），但是对于大部分的公司已经够用了，所以在Redis6.0以后，多线程机制默认是关闭的，如果需要使用，则要在redis.conf配置文件中修改，主要改两个地方：

Redis基于内存操作、数据结构简单、多路复用和非阻塞I/O等特性，避免了不必要的上下文切换，在单线程的环境下依旧很快。但对于大数据的key删除还是会卡顿，因此在4.0版本中引入了多线程unlink key/flushall async等命令，主要用于Redis数据的异步删除。而在Redis6/7中引入了I/O多线程的读写，增加了吞吐量，而命令的执行依旧是有主线程串行执行的，因此在多线程下操作Redis既能保持良好的性能和响应速度，并且不会出现线程安全的问题。